The subject matter of this patent application is at least partially in support of a proposal to 3GPP2 TSG Core Networks (TSG-X) Packet Data Serving (PDS) work group (WG). However, the application is not to be deemed limited to such specifications which may be published by such body as 3GPP2.
The following aspects regarding an end-to-end (E2E) QoS solution have been previously agreed in the PDS WG: the use of enhanced flow mapping/treatment protocol for QoS signaling from the Mobile Station (MS) to the Packet Data Serving Node (PDSN); provide a capability in the Packet Data Serving Node (PDSN) to request a Radio Access Network (RAN)-PDSN (R-P) connection with specific QoS parameters; and adopt an approach that the MS send QoS Requirements to the PDSN, and that the PDSN send the MS QoS requirement to the RAN.
FIG. 1A is a session diagram 100 showing a conventional QoS negotiation procedure in a cdma2000-type network. Network entities involved during the session include, but are not limited to, the Mobile Station (MS) 110, Radio Access Network (RAN) 120 and Packet Data Serving Node (PDSN) 130.
At step 101, after exchanging the application level information (not shown in the diagram), the MS 110 sends a 3GPP2-RSVP Resv message to the PDSN 130 containing QoS attributes and traffic filter templates (TFTs) in the 3GPP2 object for both the receiver and the sender.
Step 102, after successful authorization of the requested QoS attributes, the PDSN 130 processes the request, extracts the radio-related QoS parameters and generates the cdma2000 Bearer Service QoS parameters. The PDSN 130 requests the RAN 120 to establish a bearer with the appropriate QoS parameters (link level QoS).
The RAN 120 acknowledges the session update message at step 103. Then at step 104, the RAN 120 uses its resource management to determine if it can honor the request, and requests establishment of a Service instance to the MS 110 with the granted link level QoS and assigned Service Reference Identifier (SR_ID).
At step 105, the MS 110 accepts the request and at step 106 the RAN 120 sends an R-P setup message to the PDSN 130. The message may contain actual granted QoS parameters, e.g., if the requested QoS parameters could not be honored by the RAN 120 (to be used for accounting purposes).
At step 107, the PDSN 130 acknowledges the R-P setup message and sends the ResvConf message to the MS 110 at step 108.
It has been found that the above described signaling approach has collocation problems between the procedures performed over the different interfaces.
More specifically, a problem that arises with the conventional QoS signaling approach is that since the SR_ID is only assigned during the auxiliary service instance setup procedure (step 104), the MS 110 cannot correlate the higher layer QoS signaling (i.e., the RESV signaling) with the service instance just established at step 104 and 105. In other words, the MS 110 accepts an auxiliary Service Instance (SI) establishment request without knowing for which application the SI is established. The correlation is only established in the MS 110 after step 108. This procedure may violate the design concept that the MS 110 should know which service instance is established for which application.
Another problem with the conventional QoS signaling approach is that when the R-P update message is sent by the PDSN 130 in step 102 to check the resource availability, no SR_ID is assigned. Therefore, when the PDSN 130 later receives the R-P setup request message in step 106 from the RAN 120, the PDSN 130 cannot correlate the R-P update message and the R-P setup request message, and thus, cannot correlate the RESV message (step 101) with the R-P setup request message (step 106). As a result, the PDSN 130 does not know whether the SR_ID carried in the R-P setup request message is for the TFT carried in RESV message. As a result, the PDSN 130 does not send a RESV_CONF response to MS 110 with the assigned SR_ID.
As is described in 3GPP2 specification (Packet Data Mobility and Resource Management-X.S0011-003-C), when a Mobile Node (MN) with an active service instance hands off to a new Packet Data Serving Node (PDSN), a fast hand off procedure may be supported between the PDSNs. On detection of a condition where a handoff is required, a source Radio Network (RN), sometimes referred to as a Radio Access Network (RAN), initiates hand off procedures with the target RN (via a Mobile Switching Center (MSC)). The target RN selects a target PDSN and establishes one R-P connection for each service instance to that target PDSN. For each R-P connection so established, the target PDSN attempts to establish a P-P connection to the source PDSN. The source PDSN applies all existing link layer contexts (e.g., Point-to-Point Protocol (PPP) and compression) before sending the data packets to the target PDSN over the P-P connection. A high level message flow diagram for this type of inter-PDSN handoff is shown in FIG. 1B, where Src represents “Source” and Tgt represents “Target”.
As is explained in further detail below, this conventional inter-PDSN handoff technique does not consider how to provide QoS over the R-P network, and the external network, during and after handoff. The QoS requested by a MN may include a specific data rate and error rate, and in general may specify a certain data throughput based on an application of interest. For example, the MN may request a different QoS when engaged in a Voice over Internet Protocol (VoIP) application (e.g., one having low latency) than when involved in a typical web browsing application or a streaming video download application.
More specifically, when using the conventional fast PDSN handoff procedure, and after the P-P connection is established, the target PDSN does not have knowledge of the MN QoS requirements, or of the QoS policy to be applied to the service instance. As a result of this deficiency, no Internet Protocol (IP) QoS can be supported over the R-P network between target RN and target PDSN, as well as over network between source PDSN and target PDSN for the packet traffic transferred in the reverse direction.
It is noted that in current practice of particular interest to the preferred embodiments of this invention the Handoff Request message sent from the Src RN to the Tgt RN can carry one QoS-related parameter: “Non-Assured Mode Packet Priority”, which indicates the priority of a non-assured packet data service as specified in 3GPP2 A.S0014-B, v. 1.0, Section 4.2.41. However, the information conveyed by this field is insufficient for the Tgt PDSN to derive a QoS policy for the MN.